[WIP] Change inheriting valued tags to override #1955
Conversation
chrislemaire
force-pushed
the
1950-inherited-tag-values
branch
from
e54e8bc
to
1bae3f9
Compare
Old behaviour of inheriting tags with values was that tags added to, for instance, a posting, would be added to the tags, possibly overriding the tags of the transaction. Or, in other words, the transaction tags were added to the posting tags, as there was no sense of overriding a tag. The new behaviour is that tags are now overridden when a lower level re-uses that tag name. For instance, when defining a transaction with tag t:v and posting with tag t:v2, only t:v2 remains on the posting, overriding the transaction tag. Perhaps it would be desirable to add an option for additive tags over overriding tags, as it may well be useful at times to add to tags in the parent.
chrislemaire
force-pushed
the
1950-inherited-tag-values
branch
from
1bae3f9
to
2f9439f
Compare
There was a problem hiding this comment.
I think it makes sense to override in hierarchical order, meaning that the closer a tag is to the posting, the higher the precedence. This means:
- Tag defined for the posting
- Tag defined for the transaction
- Tag defined for the account
- Tag defined for the nextmost parent of the account up to the top of the account hierarchy
Another way to look at it: This order ensures that the "most specific" tag is used. Accounts are defined for the whole accounting setup and are therefore really general. Transactions are more specific as they are one instance where the account is used. The posting is the most specific.
And a third reason for this order: The closer a tag is to the posting, the higher the likelihood that the author intended the tag to be used. Tags that are defined further away from the posting (maybe even in another file) can be forgotten, so it would be weird if they would have a higher precedence.
| account a:b ; atag:B | ||
|
|
||
| $ hledger -f- accounts tag:atag=a | ||
| a |
There was a problem hiding this comment.
There could be more tests for the combination of transaction/posting and account tags:
| a | |
| a | |
| # 24. Transactions can override the tags of used accounts | |
| < | |
| account a ; atag:A | |
| account a:b ; atag:B | |
| 2023-01-01 Test | |
| ; atag:C | |
| (a:b) 10 € | |
| $ hledger -f- bal --pivot=atag | |
| 10 € C | |
| -------------------- | |
| 10 € | |
| # 25. Postings can override the tags of their accounts | |
| < | |
| account a ; atag:A | |
| account a:b ; atag:B | |
| 2023-01-01 Test | |
| ; atag:C | |
| (a:b) 10 € ; atag:D | |
| $ hledger -f- bal --pivot=atag | |
| 10 € D | |
| -------------------- | |
| 10 € |
There was a problem hiding this comment.
I've added your tests as suggested and I'm thinking of more tests that should be relevant to this ordering with multi-valued tags. Thank you very much for taking the time to look into some tests!
chrislemaire
changed the title
chrislemaire
changed the title
simonmichael
added
needs:discussion
|
Here's my related comment on the parent issue #1950, suggesting things to help move this forward: #1950 (comment) |
Resolves #1950
Old behaviour of inheriting tags with values was that tags added to, for instance, a posting, would be added to the tags, possibly overriding the tags of the transaction. Or, in other words, the transaction tags were added to the posting tags, as there was no sense of overriding a tag.
The new behaviour is that tags are now overridden when a lower level element re-uses that tag name. For instance, when defining a transaction with tag t:v and posting with tag t:v2, only t:v2 remains on the posting, overriding the transaction tag. The same thing is also changed for the relation between parent accounts and accounts. Although I am less sure whether that would be desired behaviour, as parent accounts might say more about child accounts than transactions do about their postings.
Perhaps it would be desirable to add an option for additive tags over overriding tags, as it may well be useful at times to add to tags in the parent?